PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/InfoMac Digests/InfoMac Vol. 6/InfoMac 6.58

Text File | 1988-06-18 | 17.5 KB | 418 lines | [TEXT/ttxt]

List (Unformatted): INFO-MAC DIGEST V6 #58


INFO-MAC Digest           Sunday, 5 Jun 1988       Volume 6 : Issue 58

Today's Topics:
           StuffIt-140B announcement (BackGround Task bug-fix)
                             Macs on planes
                          windows for hypercard
                  Re: FINDER: there should be a way up!
                      re: smalltalk & word perfect
                             VCR for Mac II?
                      audio for CD ROM machines...
                            InvisiHDMainBo3b
                              Packet radio
                Wheels for the Mind - AppleLink Address?
                           problem with INITs


----------------------------------------------------------------------

Date: Mon, 30 May 88 14:24:50 CDT
From: [e-mail] (Werner Uhrig)
Subject: StuffIt-140B announcement (BackGround Task bug-fix)

        From: [e-mail] (Raymond Lau)
        Newsgroups: comp.sys.mac
        Subject: StuffIt 1.40A Problems
        Keywords: System 6.0 and/or MultiFinder
        Message-ID: <[e-mail]>
        Date: 29 May 88 14:11:07 GMT
        Organization: The Big Electric Cat

There is a known problem if the "Allow Background Tasks" feature under
the Options menu is checked.   All should work if it's unchecked.

Alternately, 1.40B, just a bug fix for that, is available as of this writing,
from  GEnie,CIS,MacNET.....  By this afternoon, that'll include Delphi also.

If you do not need the feature, 1.40A works fine if it's unchecked.

The problem occurs under System 5.0 (the collective numbering for 4.2) and
MultiFinder OR the new System 6.0 (collective numbering)

I neglected releasing a fix until yesterday (5/28) because I only had a
beta of System 6.0.  I wanted to make sure it worked with the "real" 6.0 first.

Sorry for the inconvenience.  I'd suggest that you mail me a copy of
any problems you may have...I do not keep up with news.  Feel free to spread
the information.

-Ray
--------
[e-mail]

------------------------------

Date: Tue, 31 May 88 16:59 EDT
From: Henry Lieberman <[e-mail]>
Subject: Macs on planes
Reply-to: [e-mail]


I have taken my Mac on airplanes many times, but it is
still somewhat risky to do so.  I've never been prevented from
flying with it, but I have had a few close calls.  The
problem is that although the Mac [old Mac with small keyboard]
will fit under many airline seats, it will NOT fit under ALL
such seats.  Example: on a DC-9, it will fit under the aisle and
center seats but not under the window seat.  Try to find out what
kind of aircraft it is before choosing your seat assignment.
[Perhaps some one will get inspired to make a survey of different
aircraft and report the results here].  On a DC-10 or 747,
it will [usually] fit into the overhead bin, but this is risky,
especially on crowded flights since others may have filled the bin with
baggage by the time you get to it, leaving no room for the Mac.
Flight attendants often object to leaving it in the closet
up front.  On commuter hops with small planes, there may be no
space for it at all.  The worst problems happen when several
people on the plane have brought Macs or other computers or bulky
baggage, so I would not recommend carrying one if you can avoid
it when you're flying to something like MacWorld.  If you ask
the airlines, they will always say no, since the regulations say
they don't have to accept luggage as big as the Mac, and they want to
discourage you from carrying it.

------------------------------

Subject: windows for hypercard
Date: Wed, 01 Jun 88 08:34:37 -0800
From: [e-mail]


Jeff Skastis <[e-mail]> writes:

>I am trying to write an XCMD that will place a window (or dialog) on top
>of the regular Hypercard window.  I would like this XCMD to plop the
>window onto the screen and return some sort of ID to Hypercard.  The
>window needs to remain above the Hypercard window at all times, but still
>let action take place in Hypercard (just like the message box and tool
>palettes).  The window is removed by another XCMD that takes the ID passed
>from the first.

I've written a window that does this.  It supports multiple, resizable
windows with color pictures, text, or dialogs in them.  However, it is
rather large and complex, consisting of a large XCMD, a special WDEF,
and a system patch.  Depending on your needs you might get by with
less.

The problems I had were how to keep Hypercard active, how to draw
stuff in the window including scroll bars and the grow box), how to
detect events in the window and inform hypercard, how to move, show,
zoom windows etc, and how to handle hiding windows when multifinder
switched out hypercard.

I decided to use a patch to GetNextEvent.  In another version, I tried
using jGNEFilter, but multifinder ignores it (bug or feature?) and
when I asked Apple they suggested I stick with the patch. This took
care of most of my problems.  Most of the actual code, however,
resides in the WDEF, not the patch-- the patch just dispatches to it.

It turns out that Hypercard stops listening to the mouse when it gets
a deactivate event.  My hack for solving this problem was to not pass
deactivate events to windows that were not my windows or DA windows.
Hypercard then remains active all the time.  Occasionally there are
problems because highlighting in hypercard's message box remains even
though my window is getting keypress events, but basically this works.

To draw stuff in the window, I pass update events to the XCMD and let
the window determine what to draw.  The window draws structure-like
items (scroll bars and grow box) and then whatever other data it has.

To detect events, I take keypresses and mouse clicks and pass them to
the WDEF as well.  My WDEF has an 'event queue' for each window, plus
a mask to determine whether to queue the event.  The events are not
the same as toolbox events, but a bit more high-level-- window moved,
window resized, close or zoom box pressed, button pressed, etc.  If an
event is queued, I post the relevant data to the window's queue
(timestamp, mouse location, button id or whatever) then return a
function key event via the GNE patch.  Each window is assigned a
function key to use for reporting events, this makes it easier for a
script to determine which window has the event.  My scripts keep a
list of window addresses (returned by the XCMD when it creates the
window) and the function key is the index of the address in the list.
So to complete the reporting of the event, the script, on receipt of a
function key event, gets the window address from the list and makes
calls the XCMD asking for the next event for that window.  The XCMD
returns a string representing the 'event record.'  Since this is
mostly all compiled code, this process is quite fast.  Hypercard is by
far the slowest link.  I use this to put up confirmation dialogs
(using hypercard's answer command) when the user clicks in the close
box of a window.

The XCMD and WDEF work together to handle commanding the windows from
hypertalk scripts.  The XCMD parses a command string to determine the
data to pass to the WDEF, supplying defaults where appropriate (when
changing text parameters, for instance, any that are not provided
default to their existing values).  It builds a record and then calls
the WDEF proc passing a pointer to this record rather than an event,
and passing a special command code (not one of the existing WDEF
codes).  The WDEF then takes over, resizing or scrolling the window,
adding or removing gadgets like the zoom and close boxes, tracking the
grow box, or whatever.

Hiding windows is handled by the patch, since Hypercard 1.2 has no
script handlers for multifinder application switched events.  This is
currently a hack-- I get the head of the window list from a low memory
global, build an array of windows, then walk through it hiding all of
those that are of my type.  Since hidewindow changes the window list,
I can't just walk through the list.  Restoring windows is done in the
opposite way.  Unfortunately, I don't record the previous window
array, and hypercard shows and hides its own palette windows, so I
have no way to restore the exact order of windows that existed before
hypercard got switched out.

Anyway, this should be enough info.  Stanford owns my window XCMD or
I'd post it.  Perhaps they will release it eventually. By then,
probably Hypercard will support multiple windows.  That will obviate
most uses of my XCMD except for the color picture, scrolling, and
zooming support.  Creating windows for Hypercard was remarkably easy,
considering how much mucking around under Hypercard I had to do.

Doug Felt
AIR, Courseware Authoring Tools Project
Stanford University
[e-mail]

------------------------------

Date: Wed, 1 Jun 88 10:31 PDT
From: Francois F. Ingrand <[e-mail]>
Subject: Re: FINDER: there should be a way up!


>Date: Tue, 24 May 88 12:18:24 EDT
>From: Pedro de Rezende <[e-mail]>

>Suppose you are at the Finder and you have open the window of a folder F
>way down in the tree directory, while having closed all windows for the
>ancestors of that folder. How do you open a sibling of F? Well, you have to
>open F's parent which can only be achieved if you start from the root (the
>disk). In other words, the Finder doesn't let you climb back up the
>hierarchy of directories (like the SFGet dialog of HFS Systems do).
>Apple may have thought of that since Finder 6.0a, which I once saw with a
>pre-release version of Juggler (before Multifinder was out), had the
>following feature. If you double-clicked on the title bar of an open
>window, the window corresponding to the parent folder would pop open,
>regardless of whether any of the ancestors folders was open. This feature
>vanished with the released Finder 6.0.

NO, It is still here, even in Finder 6.1 (System Software Vresion 6.0), but it
is not the default.

If you want to set it up, call ResEdit (mine is 1.2d1), open the Finder, open
the LAYO resource, open the only one which is in it (id 0 I guess). Look for the
:
"Title Click" (or something like that) field, and set it to yes (or 1).

And it works very fine. This one of these hidden goodies features of the
Finder.

In fact, I think that the guy ou wrote Layout (nice piece of code), a shareware
which enable you to set up some parameters of the LAYO resource (mainly,
spacial layout) should upgrape his program to take into account the new slots
which appears lately.

Hope it helps,

Felix

------------------------------

Date: Wed, 1 Jun 88 14:18:54 PDT
From: [e-mail]
Subject: re: smalltalk & word perfect

Re: Info-Mac Digest vol 6, #54
Smalltalk for the Mac II

Apple Smalltalk v0.4 is compatible with the Mac II and runs reasonably
well, given its pre-release status.  It is an implementation of Smalltalk-80
based upon the Xerox License 1 system, ie. it has no multiple inheritance
and a slightly different class structure from the License 2 system as
described in the Addison-Wesley books.  It also runs on Mac Plus and SE
machines although somewhat slowly.  It is not MultiFinder compatible and
really wants more than 1Meg to function; I run it in 2Meg with good results.
Available from APDA for $75 currently.

Apple Smalltalk v1.0 is rumored to be available somewhere around the end of
the year and is allegedly a License 1 system with a MacApp based interface
paradigm, diverging from the MVC interface of Xerox/ParcPlace Systems (see
next note) Smalltalk.  I know little more of this at this time.

ParcPlace Systems of 2400 Geng Road, Palo Alto, CA is a spinoff from the
Smalltalk founding group of Xerox PARC.  They have excellent Smalltalk-80
implementations available for Sun, Apollo, Hewlett/Packard and Macintosh
Plus, SE, and II computers at the present time.  Their Smalltalk-80 systems
are full implementations of the Xerox License 2 systems described in the
Addison-Wesley books, with many enhancements.  The Mac based systems are
designed for a minimum 2.5Meg RAM configuration and include basic, extended
and developer systems with full support for the Mac II color capabilities.
They are MultiFinder compatible, assuming sufficient RAM.  Unaccelerated Mac
Plus and SE systems are quite useable and the Mac II system is benchmarked
at 108 Dorado (the Smalltalk Dorado reference is 100).  These systems are
code compatible across hardware platforms to a very high degree.

Re: Info-Mac Digest vol 6, #54
Word Perfect for Mac

I have a copy of the Word Perfect betaware and the final release 1.0
product.  It works, has many features, and I think it is the worst word
processor for the Mac I have ever seen.

Never before, for a Mac word processor, has it been ABSOLUTELY REQUIRED to
have the manual open on the desk to get beyond the simplest operations of
the program.  This seems a terrible kludge and a level of complexity simply
uncalled for.  Even Word is elegant and simple by comparison.

I heartily suggest choosing some other word processer if such exists to
meet your requirements.

Godfrey DiGiorgi
[e-mail]
Wed, Jun 1, 1988

The above remarks are my own.

------------------------------

Date:     Tue, 31 May 88 07:35:38 PDT
From: [e-mail]
Subject: VCR for Mac II?

Does anyone know of an editing video cassette recorder which works off a
Mac II?  Here's what I want to do:

(1) Generate individual frames on a color Mac II.  The time to generate a
single frame may be long (> 1 minute).

(2) Record each frame on a VHS VCR.  This involves backing up the tape
sufficiently, starting the tape movement, recording the Mac II frame on one
or more successive frames on the tape, stopping the tape.  The recording
should be triggered by the Mac II, so it can be left unattended.

(3) Take the completed tape and play it back at full speed on a standard TV
set (and optionally play it back the Mac II).

The key point is that the time taken to generate the frames is long.  So a
VCR which merely converts the Mac II video signal into NTSC format and
records that is no good.

    Charles Karney
    Plasma Physics Laboratory   Phone:   [phone]
    Princeton University        MFEnet:  [e-mail]
    PO Box 451                  ARPAnet: [e-mail]
    Princeton, NJ 08543-0451    Bitnet:  [e-mail]

CC:
        [e-mail]
        KARNEY

------------------------------

Date: Wed, 01 Jun 88 15:48:18 EDT
From: Jeremy Bornstein <[e-mail]>
Subject: audio for CD ROM machines...


Would someone please give me a pointer to the DA which allows one to make
the CD-ROM drives play audio CDs?  It would be much appreciated.  Please
reply to [e-mail].  Thanks!

-jeremy bornstein

------------------------------

Date: Wed, 01 Jun 88 14:12:30 EDT
From: Atul Butte <[e-mail]>
Subject: InvisiHDMainBo3b


I have a file called InvisiHDMainBo3b on my hard drive. It is in the
root directory. It takes up 325460 bytes in the data fork, and has no
resource fork. It is flagged as Invisible. I recognized the Bo3b as the
name of someone from Apple (see your TechNotes). What is this file? Do I
need it? It's taking up a lot of room.


_______________________________________________________________________
Atul Butte
Brown University           /-------\    /---------\
.                          !  OK   !    !  CANCEL !
.                          \-------/    \---------/
[e-mail]

------------------------------

Date: Tue, 31 May 88 11:39 N
From: <[e-mail]>
Subject: Packet radio

I am posting this messages for a friend.

Hi, in the free world of ham radio a lot of people are interested in packet
radio. I want to know more about packet-radio-software for the Mac. Does anyone
know something about Brincomm, 2404 Stockton Pl Marietta CA. Any information is
highly appreciated.
Peter van der Hoog
Please mail to
[e-mail]

------------------------------

Date: Thu, 02 Jun 88 10:49:16 EDT
From: Atul Butte <[e-mail]>
Subject: Wheels for the Mind - AppleLink Address?

I understand that it is possible to send mail and files from BITNET onto
AppleLink.  In that case, what is the AppleLink address of the people who
manage contributions for Wheels for the Mind? I think it would be great
if contributors could just EMail their submissions (articles, screen
dumps) to the right people instead of using USnail mail. In addition,
this would be a great non-commercial use of the AppleLink-BITNET
connection.

Thanks in advance.
_______________________________________________________________________
Atul Butte
Brown University           /-------\    /---------\
.                          !  OK   !    !  CANCEL !
.                          \-------/    \---------/
[e-mail]

------------------------------

Date: Thu,  2-JUN-1988 13:47  +0200
From: "KARL::WIM" <[e-mail]>
Subject: problem with INITs

        I have a problem with my INITs. On startup some of them are
        executed twice. This happened after I changed the ID of one INIT
        31 to 30 and then pasted in another with ID 31 into the system file.
        Question is: then why are the other INITs (in the system folder)
        executed twice.
        I don't feel like playing around with the debugger. Which guru
        helps me out ??
        (I'm running System 4.2, if that helps)

        W.Elhorst
        [e-mail]

------------------------------

End of INFO-MAC Digest
**********************

ACTION>